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Abstract.  We  derive  expressions  for  remote  pro¬ 
cedure  call  (RPC)  retransmission  timeout  values  that 
minimize  the  weighted  sum  of  total  elapsed  time,  operat¬ 
ing  system  kernel  costs,  and  network  charges.  Currently 
we  select  RPC  retransmission  timeouts  to  minimize  net¬ 
work  utilization,  an  operating  point  chosen  with  our  net¬ 
works’  low  bandwidth  in  mind.  When  public  utilities  pro¬ 
vided  digital  service  becomes  popular,  we  will  routinely 
make  requests  to  servers  across  town  and  across  nation 
and  we  will  pay  for  each  message  that  we  send.  These 
networks  may  offer  various  grades  of  service,  each  with 
different  loss  and  delay  characteristics.  In  such  an 
environment,  choosing  the  retransmission  timeout  and 
grade  of  service  that  minimize  our  costs  is  not  obvious. 
Our  approach,  illustrated  with  a  simple  RPC  algorithm, 
can  be  applied  to  other  remote  invocation  mechanisms. 
We  can  incorporate  the  expression  for  the  optimal 
retransmission  timeout  that  our  approach  generates  into 
the  communication’ s  software  of  distributed  operating 
systems. 

This  work  has  been  supported  in  part  by  the  Defense  Advanced 
Research  Projects  Agency  (DoD),  ARPA  Order  No.  4871,  monitored  by 
the  Naval  Electronic  Systems  Command  under  Contract  No.  N00039- 
84-C-0089  and  by  an  American  Electronics  Association  Faculty 
Development  Fellowship.  The  views  and  conclusions  contained  in  this 
document  are  those  of  the  author  and  should  not  be  interpreted  as 
representing  official  policies,  either  expressed  or  implied,  of  any  of  the 
sponsoring  organizations  or  of  the  U.S.  Government. 


1.  Introduction 

Consider  a  remote  procedure  call  (RPC)  between  a 
requestor  site  and  a  server  site  [1].  Since  both  the  net¬ 
work  and  the  server  may  lose  messages,  sometimes  the 
requestor  must  retransmit  its  RPC  request  one  or  more 
times.  Similarly,  since  both  the  network  and  the  requestor 
may  lose  messages,  sometimes  the  server  must  retransmit 
its  reply  one  or  more  times.  Since  the  server’s  service 
time  varies  depending  on  the  its  load  and  processor  speed, 
most  existing  RPC  implementations  retransmit  infre¬ 
quently,  assuming  that  the  network  rarely  loses  messages 
and  that  the  server  will  eventually  respond.  However,  in 
some  networks,  the  probability  of  message  loss  can  be 
high.  Extended  local  area  networks  (LAN)  experience 
buffer  overflow  at  LAN  bridges.  Internet  gateways  drop 
packets  due  to  congestion  by  caused  by  stream  protocols. 
Aloha  and  slotted  Aloha  networks  lack  collision  detection 
and  lose  messages  with  high  probability.  The  probability 
of  message  loss  increases  with  message  size,  and  many 
request-response  protocols  can  send  many  kilobytes  of 
data,  e.g.  encryption  key  servers,  authentication  servers, 
and  and  network  paging  servers.  Modeling  existing  net¬ 
works,  we  introduce  an  RPC  cost  function  that  accounts 
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for  kernel  costs,  network  costs,  and  end-to-end  message 
transmission  delay,  and  minimize  it  as  a  function  of  the 
protocol  retransmission  timeout. 

When  public  utility  provided  networks  become 
popular,  we  can  expect  to  pay  for  each  message  we 
transmit.  Perhaps  the  networks  will  offer  various  grades 
of  message  reliability  and  message  transmission  delay. 
Unreliable  messages  cost  less  than  highly  reliable  mes¬ 
sages.  Slower  messages  cost  less  than  faster  messages. 
Modeling  these  future  networks,  we  minimize  our  RPC 
cost  function  by  simultaneously  finding  the  optimal 
retransmission  timeout  and  grade  of  service  to  request. 

In  Figure  1  we  illustrate  our  RPC  retransmission 
policy.  The  requestor  retransmits  its  RPC  every  x  mil¬ 
liseconds  until  it  receives  the  server’s  reply.  We  denote 
the  probability  that  a  message  is  lost  by  p ,  the  probability 
that  it  is  delivered  by  q  =  1  -  p ,  the  operating  system 
kernel’s  cost  per  message  by  Kr  and  the  network’s  charge 
per  message  by  Mr  ( y ,  p ),  where  y  denotes  the  message’s 
expected  transmission  delay.  We  denote  the  time 
between  retransmissions,  the  retransmission  timeout,  by  x, 
the  server’s  service  time  density  by  f(t),  and  the 
expected  service  time  by  x. 

1.1.  RPC  cost  function 

We  define  the  total  RPC  cost  L  as  the  weighted 
sum  of  the  elapsed  time  between  the  requestor’s  initial 
transmission  and  its  first  reception  of  the  RPC’s  results, 
the  cost  imposed  on  the  operating  system  kernels  by  mes¬ 
sages  sent  by  both  the  requestor  and  the  server,  and  the 


Figure  1.  Figure  1.  Behavior  of  the  RPC  algorithm  we 
consider  here. 


charge  that  the  network  imposes  for  the  transmitted  mes¬ 
sages.  Denote  the  expected  number  of  message  sent  by 
n,  the  expected  elapsed  time  by  T,  and  the  expected  RPC 
cost  function  by  L . 

L  =a -T+  b  ■  n  Kr  +  c  •  n  ■  Mr(y ,p) .  (1) 

Notice  that  the  weighting  constants  a,  b,  and  c  must 

translate  each  component  of  this  sum  into  some  common 

unit  of  cost,  say  milliseconds.  Since  we  can  rescale  Kr 

and  Mr ( y , p ),  without  loss  of  generality,  we  set  a,  b  and 
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c  to  1. 

1.2.  Outline 

In  Section  2  we  calculate  optimal  timeouts  for 
existing  networks  in  three  steps.  We  first  calculate  the 
optimal  timeout  assuming  that  message  transmission 
delay  is  negligible  and  result  messages  are  not  lost.  This 
models  busy  servers.  Busy  servers  may  repeatedly  drop 
requests,  but  once  it  receives  one,  it  never  drops  its 
response.  Next  we  extend  the  model  to  include  lost  result 
messages.  Finally,  we  add  network  transmission  delay  y . 
In  Section  3  we  consider  networks  with  tunable  loss  and 
delay  parameters,  where  slow  messages  cost  less  than  fast 
messages  and  less  reliable  messages  cost  less  than  more 
reliable  messages.  We  simultaneously  minimize  the  RPC 
cost  function  L  over  the  retransmission  timeout  t  and  the 
optimal  network  transmission  time  y  and  loss  parameter 
p  to  request  In  Section  4  we  discuss  how  to  incorporate 
our  results  in  distributed  systems.  We  draw  conclusions 
in  Section  5. 

2.  Optimal  retransmission  timeout 

In  this  section  we  derive  the  optimal  retransmission 
timeout  xopt  by  evaluating  the  cost  function  and  setting  its 
derivative  with  respect  to  the  retransmission  time  T  to 
zero,  given  that  the  network  does  not  charge  for  messages 
sent(Mr(y,/?)  =  0). 

2.1.  No  lost  replies.  No  message  transmission  time. 


server  receives  the  RPC  request  contributes  kernel  cost 
Kr  and  time  x  to  the  cost  function  L .  Since  the  requestor 
continues  retransmitting  the  RPC  request  every  x  seconds 
until  it  receives  the  results,  it  retransmits  |_r/xj  times  dur¬ 
ing  the  service  time  interval  t .  The  initial  request  and  the 
one  (and  only)  reply  contribute  2  Kr . 


L  =  ipkq(Kr+x)k+2Kr+jf(t) 

i=l  0 

Recall  the  expected  value  of  a  geometric  series. 


' 

" 

t+ 

t_ 

X 

Kr 

dt 


£  <7  *  pk~y  =  -. 

*=i  ? 

We  integrate  and  replace  the  first  part  of  the  integrand 
with  the  expected  service  time  x.  We  replace  the 
geometric  series  with  its  value  p/q,  and  rewrite  the  floor 
as  a  summation. 


L  =  £(Kr+x)  +  x+2Kr+Kr'£  J 

Q  j—\  jx 

We  minimize  the  total  cost  L  by  setting  its  derivative  with 

respect  to  x  to  zero. 


+  J  Jf(Odt=0. 

dx  q  dx  y=1  /T 


We  apply  the  chain  rule  and  discover  that  derivative  of 
the  summation  telescopes. 

,  -  <7+U* 

J  jf(t)dt=-Kr'£jf(jx). 

7=1  JX  7=1 

When  the  RPC  service  time  is  distributed  exponentially, 
then  this  is  a  geometric  series  and  is  easily  evaluated. 


£;/(yx)  =  4z^ 

7=1  *  7=1 


-jxlx 


,  — T/  X 


x  (1  -e  -T/i)2 
The  optimum  timeout  satisfies  a  quadratic  equation  in 


,  -Xl x 


Momentarily  assume  that  the  RPC’s  result  message 
is  never  lost  Each  transmission  sent  and  lost  before  the 
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<7  x  (l-e-*1*)2 

We  find  the  roots  of  this  quadratic  equation  by  employing 
the  quadratic  formula. 


\  q  Kr  1 

I 

\ 

'qKr  ' 

2  1 

e-T/x  = 

— -  +  i 

±i 

- —  + 1 

-1 

p  2x 

<  1  J 

1 

l 

p  2x 

1  J 

J 

Since  the  optimal  timeout  must  be  positive,  we  employ 
the  smaller  root. 


'Copt  -T  In 


qKr 

p  2x 


qKr 
p  2x 


1  2 


+  1 


1/2 


-1 


Unfortunately,  our  precision  has  left  us  with  a  clumsy, 
albeit  exact,  expression.  As  we  are  seeking  something 
that  system  programmers  can  exploit,  we  approximate  L 
by  ignoring  the  floor  within  the  integral.  This 
approximation’s  accuracy  decreases  as  t  grows  larger 
than  jc. 


K 

L=R(Kr+i)  +  2Kr+x(l  +  —  ). 

q  * 

We  set  the  derivative  of  this  expression  to  zero  or,  alter¬ 
natively,  apply  the  approximation  In  (1  -  x)  -»  -x  to  the 
equation  for  xopt  above,  and  obtain 


This  timeout  is  only  accurate  on  local  networks 
where  the  transmission  time  is  negligible  and  where  RPC 
requests  are  lost  primarily  because  the  RPC  server  is 
overloaded.  In  the  remainder  of  this  section  we  include 
lost  responses  and  network  transmission  time  to  the 
model.  Most  of  the  hard  work  is  over. 


2.2.  No  network  transmission  time 

We  now  modify  our  cost  function  to  account  for 
lost  replies.  Ignore  message  transmission  time  for  a 
moment  longer. 


L  =  Z(Kr+x)  +  2Kr  +  q  j/(0 


t  + 


Kr 


dt 


+P  J fit) 


[  x  +  ATr  J  dt. 


+P  2,j  (Q+q)Kr  +T)  (1-  q2y~lq2 
M 


The  server’s  result  transmission  is  delivered  with  proba¬ 
bility  q  and  is  lost  with  probability  p .  The  first  integral 
accounts  for  latency  and  retransmission  costs  when  the 
result  is  delivered  successfully.  The  second  integral 
accounts  for  latency  and  retransmission  costs  through  the 
instant  when  the  result  transmission  is  lost,  in  which  case 
the  latency  is  a  multiple  of  x.  The  geometric  series  in  q2 
accounts  for  the  kernel  costs  and  latency  that  accrue  after 
the  result  transmission  is  lost  until  both  a  retransmission 
and  the  reply  to  the  retransmission  are  successfully 
delivered.  The  factor  of  (1  +  q)  corresponds  to  the 
expected  number  of  transmissions  for  each  retransmission 
cycle.  With  probability  1  the  requestor  retransmits.  With 
probability  q  the  retransmission  reaches  the  server  and  the 
server  replies.  (We  assume  the  server  holds  the  results  of 
the  RPC  for  a  long  time;  clearly,  some  form  of  garbage 
collection  can  eliminate  old  results).  We  collapse  the 
geometric  series  and  replace  the  floor  with  a  summation. 
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L  =  ^-  (Kr  +x)  +  2  Kr  +p  ((l  +  q)  Kr  +x)  q  2 

<7 

„  o+i)  * 

+  q  x  +  (Kr+p  t)]l  J  jf(t)dt. 

i- 1  j  z 

We  minimize  this  quantity  by  setting  its  derivative  to 
zero. 

^L  =  2.+pq~2_{Kr+pz)j:jfUx) 

dx  q  y=i 

„  (/+1)r 

+PS  J  jf(t)dt=  0. 

y=l  j  X 


cost  function  L  for  uniform,  exponential,  and  constant 
service  time  distributions  of  equal  expected  service  time 
x.  We  see  that  our  approximation  of  xop,  is  very  close 
indeed. 

2.3.  Message  transmission  time 

We  are  now  ready  to  account  for  message  transmis¬ 
sion  time  by  adding  to  each  message  its  expected  message 
transmission  time  y .  We  proceed  in  the  familiar  manner 
to  derive  the  optimal  timeout  xopt  that  we  seek. 


When  f(t)  is  exponential,  we  easily  find  the  cost 
function  L . 

L  =  -P-  (Kr  +  X)  +  2 Kr  +  p  ((1  +  q)  Kr  +x)  q  2 
Q 

e~xl* 

+  q  x+  ( Kr+p  X)  - - —j. 

l-e 


However,  this  expression  is  not  in  quadratic  form  and  we 
can  not  find  xop,  in  closed  form.  Although  we  could 
apply  the  Newton-Raphson  technique  to  approximate  this 
expression’s  root,  we  choose  instead  to  approximate  xopl 
by  ignoring  the  floor. 

L  =  —  (Kr  +x)  +  x  +2Kr  +p  ( (1  +  q)Kr  +  x)  q~2 
<7 

+  Kr  x  X"1 . 

We  set  its  derivative  to  zero  and  solve  for  xop, 


Let  us  investigate  our  approximation’s  sensitivity  to 
the  service  time  distribution.  In  Figure  2  we  plot  the  cost 
function  L  and  our  approximation  of  xopl.  We  plot  the 
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Figure  2.  Figure  2.  Cost  function  versus  timeout 
x  =  15,  Kr  =  5,  q  =  .8,  y=(0  and  10). 
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L  =  ^-  +  q  (2 y+x) 
<7 


+  P 


J/(0 


y+t 


dt  +  2y  +  -V 

<7 


+  Kr 


Z  +  (l+<?)J/(0 

<7  o 


2y  +  t 
x 


dt 


+  2-q  I /(<) 


dI  +  £jl+il 


When  the  server’s  service  time  is  exponentially  distri¬ 
buted,  we  can  evaluate  the  cost  function.  However,  as 
this  does  not  lead  to  a  closed  form  expression  for  xopt ,  we 
immediately  derive  an  approximation  for  L  by  ignoring 
the  floors. 


Retransmission  Timeout 

Figure  3.  Figure  3.  Cost  function  versus  timeout. 
x  =  15,  Kr  =  5,  q—  .5,  y  =  10  and  y  =  100,  service  ex¬ 
ponential,  transmission  time  constant. 


L  ~  —  +  q  (2 y  +x)  +  p 
<7 


y  +x+ 2 y  +  —t 

r 


(2) 


+  Kr 


P  |  d  +  g)2y  ,  2  i  *  i  P 


We  set  the  derivative  with  respect  to  x  to  zero,  replace  p 
by  1  -  q ,  and  solve  for  the  optimum  timeout  T. 

I  Kr  ((l+q)2y +x)  m 

V  =  - iTvi - •  (3) 

In  Figures  4  and  5  we  plot  the  cost  function  and  its 
standard  deviation  for  several  sets  of  parameters.  Note 
that  the  standard  deviation  grows  quickly  when  the 
timeout  exceeds  xop,  and  that  our  approximation  for  xopt 
holds  for  both  constant  and  exponential  message 
transmission  delay. 


Retransmission  Timeout 

Figure  4.  Figure  4.  Mean  and  standard  deviation  of  cost 
function  versus  timeout,  x  =  15,  Kr  =  5,  q  =  .8,  y  =  10, 
service  exponential,  transmission  time  constant  and  ex¬ 
ponential. 


3.  Paying  for  faster  messages 
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Since  public  utility  provided  digital  communication 
will  eventually  become  popular,  let  us  investigate  how 
one  possible  feature  of  future  networks,  being  able  to  pay 
for  reduced  transmission  delay  and  lower  error  rates, 
affects  our  timeout  calculations.  Suppose  the  network 
charges  us  for  each  message  we  send,  charging  more  for 
decreased  transmission  time  and  lower  loss  rates.  We,  as 
network  subscribers,  specify  the  type  of  service  we 
desire,  and  pay  a  service  charge  based  on  the  network 
resources  we  consume  [2].  For  example,  we  can  specify 
lossy  service  and  pay  less  per  message,  but  have  to 
retransmit  more.  For  our  purposes,  assume  we  can  specify 
the  message  transmission  delay  y ,  y  >y0,  and  loss  proba¬ 
bility  p ,  p  >p0,  and  pay  a  charge  Mr{  y ,  p)  >  0,  decreas¬ 
ing  in  both  y  and  p,  for  each  message  we  send  (y0  is  the 
minimum  network  delay  and  p0  is  the  minimum  message 
loss  probability).  We  find  the  optimal  retransmission  time 
and  service  grade  ( xopt ,  yopt,  popt  )  subject  to  the  con¬ 
straints  x  >  0,  y  >  y0»  and  p  >  p0  that  minimize  our  RPC 
cost  function. 

Recall  the  definition  of  the  RPC  cost  function, 
equation  (1).  Assume  again  that  the  scaling  factors  a,  b, 
and  c  have  already  been  included  in  Mr(y ,p)  and  Kr. 
We  approximate  the  RPC  cost  function  by  combining 
equations  (1)  and  (2). 


L  =  —  +  q  (2y  +  x)  +  p 
<7 


y  +  x+  2y  +  —z 

r 


+  (Kr  +Mr(y,p )) 


(\+q)2y  +x  |  2  |  p  (l  +  2<7) 


We  employ  the  Kuhn-Tucker  method  [3]  of  constrained 
optimization  to  minimize  L .  The  Kuhn-Tucker  method 
optimizes  L  by  setting  its  partial  derivatives  to  zero  while 
maintaining  all  of  the  constraints.  We  make  this  example 
concrete  by  considering  a  possible  message  cost 
Mr(y,p )  and  constraint  gp . 

Mr(y,p)  =  Y 

gP  =P  ~Po  =  0. 

gy  =y  -y o^o. 

We  introduce  Lagrange  multiplier  Xy  corresponding  to 
constraint  equation  gy.  The  Kuhn-Tucker  conditions 
reduce  to 


3y 


0 


gy  ~~  0 

x  >  0,  and  y  >  0  . 


This  constrained  optimization  problem  is  easily 
solved  since  p  is  given  and  the  constraint  on  y  is  linear. 
We  discover  that  the  optimal  pair  (xopl ,  yopt )  is  simply  the 
solution  to  the  unconstrained  problem  unless  yopt  <  y0,  in 
which  case  the  optimal  transmission  time  y  is  y0  and  the 
optimal  retransmission  timeout  is  xop,  as  calculated  in  (3) 
after  substituting  Mr(y0,p)  +  Kr  for  Kr  and yopl  for  y . 


(Kr+Mr(y0,p))((l+q)2y0  +  x) 


'v-'V  (1  -q2) 

In  Figure  5  we  plot  several  optimal  timeout  and 
optimal  transmission  delays  as  a  function  of  the  constant 
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of  proportionality  a.  When  Mr(y,p)  is  differentiable  and 
decreasing  in  y  and  p ,  we  can  always  apply  the  Kuhn- 
Tucker  algorithm  to  find  the  channel  parameters  yopt  and 
popt  and  retransmission  time  xopl  that  minimize  L .  Com¬ 
pare  the  two  darkest  pairs  of  lines  which  only  differ  by 
the  kernel  cost  Kr.  The  darkest  line  has  larger  Kr.  We 
see  that  this  pushes  the  retransmission  time  higher  but  lets 
us  pay  for  faster  channel  delay. 

4.  Implementation 

We  can  take  advantage  of  these  timeout  calcula¬ 
tions  in  real  distributed  systems  by  incorporating  them 
into  network  code.  We  can  cache  estimates  of  the 
expected  service  time  x,  the  loss  parameter  p ,  and  the 
round  trip  message  delay  2  y  to  various  destinations.  We 

Optimal  timeout  zopt  and  transmission  time  >op< 


Proportionality  constant  alpha  of  Mr  (y  j> )  =  aJy 

Figure  5.  Figure  5.  Retransmission  timeout  x^,  and 
transmission  delay  y^,  are  functions  of  the  transmission 
delay  cost  function Mr(y,p)  =  oJy . 


can  update  a  destination’s  estimates  every  time  we  com¬ 
plete  an  RPC.  Where  no  estimates  exist,  we  can  initialize 
them  to  some  set  of  default  values.  Estimates  for  sites 
with  which  we  communicate  frequently,  nameservers, 
authentication  servers,  page  servers,  will  improve  and 
converge. 

It  is  more  difficult  to  exploit  Section  3’s  results, 
finding  both  the  network’s  optimal  grade  of  service  and 
the  optimal  timeout,  because  we  lack  closed  form  approx¬ 
imations.  However,  we  can  calculate  these  values  by 
solving  the  Kuhn-Tucker  equations  once  and  place  them 
in  the  application  software  or  operating  system.  Given  a 
specific  network  cost  function  Mr(y,p),  we  could  con¬ 
struct  a  table  of  the  optimal  x,  y ,  and  p  indexed  by  the 
remaining  variables  x  and  Kr . 

4.1.  Stability 

Address  stability  issue.  Since  losses  may  occur 
from  buffer  overflow,  raising  the  timeout,  not  lowering  it, 
is  the  measure  that  leads  to  stable  behaviour.  However, 
as  congestion  and  losses  increase,  the  server’s  estimation 
of  x  increases  as  well.  If  the  server’s  queue  holds  four 
jobs,  then  its  estimate  of  x  increases  to  5xbar0,  where  J0 
denotes  the  empty  queue  behaviour. 

When  more  than  one  service  provider  exists,  a 
related  problem  is  choosing  the  timeout  at  which  we  give 
up  on  one  service  provider  and  go  on  to  the  next.  For 
example,  the  4.3  bsd  UNIX  nameserver  accepts  the 
names  of  three  alternative  servers  which  it  tries  in  round- 
robbin  order.  We  can  apply  our  technique  to  calculate  this 
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timeout 

5.  Conclusions 

Selecting  protocol  timeout  values  taxes  the  intuition 
of  system  programmers.  Historically  RPC  timeout  values 
have  been  chosen  long  to  minimally  impact  the  network 
load  and  because  the  programmers  assumed  that  losses 
were  rare.  At  the  minimum,  our  expression  for  the 
optimal  retransmission  timeout  (3)  sheds  light  on  the 
intuitive  process  of  selecting  timeouts.  We  believe  our 
expression  replaces  the  black  art  of  selecting  timeouts.  In 
the  future,  when  we  have  to  select  and  pay  for  the  grade 
of  network  service  that  we  use,  we  will  have  to  select 
both  the  RPC  retransmission  time  and  the  network 
transmission  delay  and  error  rate  that  we  request.  We 
solved  this  problem  by  adding  the  cost  per  message 
Mr(y,p)  sent  into  the  RPC  cost  function  L  and  then 
minimized  L  over  the  parameters  that  we  are  allowed  to 
select,  the  retransmission  time  X,  the  network  transmission 
delay  y ,  and  the  network’s  message  loss  probability  p . 

We  believe  our  RPC  cost  function  reflects  the 
tradeoffs  that  protocol  designers  make.  However,  the 
optimal  retransmission  timeout  that  we  calculate  (3)  is 
only  as  good,  of  course,  as  the  parameters  that  drive  it,  the 
kernel  cost  per  message  Kr,  the  expected  service  time  x, 
the  probability  a  message  is  lost  p ,  and  the  round  trip 
message  delay  2  y . 

I  Kr  ((1  +<?)2y  +x) 

Xop'=<iy  (1_?2) 


One  can  extend  our  skeletal  RPC  algorithm  to  other 
request-reply  protocols.  We  can  apply  our  techniques  to 
optimize  the  Birrel  and  Nelson  algorithm  [1]  in  which  the 
server  acknowledges  all  retransmissions.  Inherently,  we 
have  assumed  that  RPCs  are  not  the  cause  of  network 
congestion  and  that  message  loss  is  independent  and 
describable  by  a  single  parameter  p .  Since  our  algorithm 
decreases  x  with  increasing  loss  probability  p ,  we  add  to 
network  congestion.  This  is  reasonable  since  stream  pro¬ 
tocols  are  the  principle  cause  of  network  congestion,  and, 
in  the  future,  charging  for  messages  will  reduce  the 
greedy  stream  protocol’s  incentive. 
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